CORRECTING AND MONITORING STATUS OF HEALTH CARE CLAIMS 

Cross Reference to Related Applications 
This Application claims priority benefit under 35 U.S.C. 1 19(e) to U.S. 
Provisional Application Serial No. 60/419,713 filed on October 17, 2002 titled 
"System and Method for Correcting and Monitoring Status of Claims for Payment for 
Healthcare Services Rendered to a Patient," which is hereby incorporated by reference 
in the entirety and made part hereof. 

Field of the Invention 
This invention relates to processing health care claims, and more particularly to 
electronic filing, correcting, and on-line monitoring of claims for payment for 
healthcare services rendered to a patient. 

Background of the Invention 
The majority of healthcare providers (physicians, dentists, etc.) obtain payment 
for medical services provided to a patient from a payer, which is generally a healthcare 
organization or insurance company administering a plan for the patient's employer. 
The form that is submitted from the healthcare provider to the payer is called a 
"claim." A claim is typically filled out by the healthcare provider. The claim should 
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indicate all information required by the payer for payment of the healthcare provider 
for the service rendered to a patient. A properly completed claim typically identifies 
the physician that provided the service, a service identification code, the patient, the 
patient's group and plan number, payer identification, the amount of the claim, co- 
payment amount, etc. 

There are two primary methods by which providers may submit claims to the 
payers: 

1) send the claims on paper using a standard paper form called a HCFA 1500 
form; or 

2) send the claims electronically. 

If the provider selects to send the claims electronically, they generally have two 
options: 

1) a direct method that utilizes a software application provided by a payer that 
only accepts claims for that payer; or 

2) a clearinghouse method that utilizes a software package provided by a 
clearinghouse that enables a provider to submit claims to multiple payers. 

Typically, if a provider elects to submit all or a portion of their claims electronically, 
they will rely on their practice management software (PMS) vendor to facilitate an 
interface between their electronic connectivity solution and their PMS system. The 
transportation of claims from the provider's office to the payer can occur via direct 
dial up connection using a modem or via the Internet. 

Once the claims are submitted, the payer then checks the claims to ensure that the 
information contained in the claim is in proper format. For example, certain service 
identification codes may only be five digits and have certain values uniquely 
identifying the service provided. In addition, the data is checked to ensure it makes 
sense in context. For example, an adult male patient visiting an obstetrician for a child 
wellness visit would cause the payer's processing system to reject the claim. A male 



2 



patient should never have need of such obstetric services, and an adult would not 
properly receive services in connection with a child wellness visit. These checks are 
implemented by the healthcare payer's claim processing system are implemented as 
'rules' embedded in the code of the payer's claim processing system. In some cases 
these 'rules' are included in the claims submission software application that resides in 
the providers office, whether the provider is using the direct or clearinghouse method 
for submitting claims. Payers have a vested interest in improving the quality of the 
rule edits that reside in front of the payer's claim processing system. 

By editing the claims at the time of submission, the provider receives 
notification of any problems with the claim immediately, which enables the provider 
to correct the claim and resubmit the claim. This process reduces the delays in the 
payment process, which leads to improved provider relations and results in fewer calls 
from the provider to the payer's support center, thereby reducing cost for both the 
provider and the payer. Furthermore, by editing the claims at the time of submission, 
the payer avoids the expense of accepting the claim, processing the claim, and 
facilitating the return of the information required to correct the claim. Accepting 
claims that will ultimately fail in the payers system generates increased expense for the 
payer as well as delay in the payment of the claim. However, these edits are not easily 
changed once embedded in the code to accommodate rule updates, even by skilled 
programmers familiar with the computer language in which the rules are implemented. 

In addition to rejecting claims for format and contextual errors, payers may also 
reject claims for reasons related to patient or provider eligibility. In those cases the 
claim may reject because: 

1) the patient is not covered by the plan or the provider is not registered with 
the payer; 

2) the patient or provider is not properly registered with the payer; 
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3) services that were rendered by the provider are not covered under the 
patient's payer plan; 

4) the information identifying the patient or provider was submitted 
incorrectly; or 

5) 5) the claim was filed after the timely filing deadline. 

Furthermore, claims may reject for reasons related to authorizations. Authorizations 
are granted by payers to patients seeking access to specialists or providers other than 
their primary care provider (PCP). If the proper authorization has not been granted by 
the payer prior to claims submission, the claim may rejected. 

The amount of information available to a provider about the status of their 
claims once they have sent them can vary dramatically, depending on the payer, the 
clearinghouse and the method used to submit the claims. In general there are three 
basic categories for the types of messages that can be returned: 

1) Claim File Acknowledgement - indicates the status of the claim file that 
was sent by a submitter. This report simply indicates whether or not the file 
was received and accepted by the payer. 

2) Claim Level Acknowledgement - preliminary status that indicates whether 
or not a claim has passed the first phase of editing. A claim accepted at this 
point is not a guarantee of payment. 

3) Electronic Remittance Advice (ERA) - final report indicating acceptance or 
denial of the claim. If the claim is accepted, in whole or in part, it will also 
indicate payment amounts. 

Even when these reports are available electronically, there is no guarantee that the 
clearinghouse intermediary will make these reports available to the provider. 

Even when information is available there is little or no consistency in the 
messages that are returned by the different payers. As an example, a provider could 
receive a different message for the same claim error from each of the payers to which 
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they submit claims. In many cases the provider must contact the payer to obtain 
clarification about the exact cause for a claim rejecting. 

Once a claim is submitted from the healthcare provider to the payer, the 
healthcare provider often has limited information regarding the status of the claims. 
Therefore, the provider is unaware of problems in the processing of claims that could 
be remedied to obtain faster payment of the claim. 

What is needed is an all payer, universal system that can ensure that the 
appropriate format for each particular payer's requirements, the information contained 
within the claim conforms to the appropriate content specifications, and checks to 
determine the patient's and provider's ability to receive reimbursement from the payer, 
when such information is available. If the claim is incorrect, then the claim should be 
rejected at the time of submission and the provider should receive immediate 
notification that details the errors. 

Once claims in the correct form are received, the system needs to format the 
claims according to each payers requirements and transmit the claims. Thereafter, the 
payer applies its rules and either rejects or accepts the claims. This information 
should be readily accessible by the provider to determine a claim's status. The system 
should enable the provider to use these status indicators to perform summary or 
detailed queries as to the overall status of their billing and quickly and efficiently 
identify claims that require attention. Ideally, the system would allow the provider to 
determine the status of a claim at all stages of its processing and receive proactive 
reports indicating when claims have either rejected or when important information is 
delayed. 

Summary of the Invention 
The system is an advanced, web-enabled, clearinghouse that facilitates efficient 
and effective claim routing and report retrieval. Before claims are submitted for 
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payment, the claims are reviewed by an internal claims editor to ensure the claims 
comply with known rules for that payer. As a claim proceeds through the various 
stages of the reimbursement cycle, each step of the claim process is captured and 
recorded. The system discovers new error messages and new verification rules are 
added to the claims editor. At times, payers provides error messages that are non-user 
friendly and ambiguous. These error messages make it difficult to determine the 
reason for a rejection. Supplementing the error code with user friendly and easy to 
understand messages helps staff identify the true reason for a rejection. In addition, 
the system performs payer profiling to identify corresponding patterns in how much 
correspondence to expect and the length of time to receive the associated 
correspondence. 

Generally speaking, the system receives practice identifying information over 
the Internet during a log on process. After a successful log into the system, a claim 
status summary is displayed that links directly to a rejected claim listing. In response 
to an activation of a rejected claim listing link, the rejected claim listing is displayed 
wherein each rejected claim listed is a link to associated detailed claim information. 
The detailed claim information display has fields to edit the associated detailed claim 
information. 

During the claim submission process, a rules verification is performed on the 
submitted claims to ensure the claims comply with the known rules for the associated 
payer. Upon successfully completing the rules verification, the edited claim is 
submitted to a payer. Rejected claims are identified and displayed for the user so that 
the errored claims can be corrected using the system 

After submission to the payers, the system may receive claim rejection data. 
This rejection information is analyzed to determine if the provided rejection code is in 
the claim management database. If the rejection code is not in the database, it is a new 
rejection code that the system has not previously encountered. The new rejection code 
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is categorized into a general rejection category. These categories include eligibility 
errors, duplicate claim errors, provider enrollment errors, coding errors, patient 
demographic errors, and payer information errors. Categorization of these errors 
enable a provider to determine where the problems are occurring within their billing 
system. In addition, a new rejection is analyzed for possible addition of new rules to 
associate with that payer. Attempting to duplicate the payment rules applied by the 
payer facilitates rejections by the system at the time of entry of the new claims, and 
thus, reduces the amount of time need to process a claim and receive payment. 

The system captures every action related to the submission of a claim from a 
provider to the payer and all of the corresponding reports and messages being returned 
by the payer to the provider. Whenever any action occurs related to a claim the system 
records the name of the individual performing the action and the date and time that the 
action was performed. The system stores all of the aforementioned data related to a 
claim in a relational database so that a customer or other user can review all aspects of 
the claims history to identify what caused the claim to reject and where and when the 
error occurred. The unique cross-referenced data structure enables a provider to view 
all aspects of the claims life cycle from important and unique perspectives. The 
system's ability to organize the data in a standardized format and also allow the data to 
be viewed in multiple ways enables a provider to efficiently and effectively improve 
the percentage of claims that are paid by the payers, increase the amount paid per 
claim and reduce the administrative expenses for both the provider and the payer. 

Brief Description of the Drawings 
Benefits and further features of the present invention will be apparent from a 
detailed description of preferred embodiment thereof taken in conjunction with the 
following drawings, wherein like elements are referred to with like reference numbers, 
and wherein: 
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FIG. 1 is a functional block diagram illustrating an overview of an exemplary 
overview of the claim management system. 

FIG. 2 is a functional block diagram illustrating an exemplary software 
architecture. 

FIG. 3 is a functional block diagram illustrating an exemplary system 
architecture. 

FIGs. 4 A and 4B are functional block diagrams illustrating exemplary flow 
charts for claim processing. 

FIG. 5 is a functional block diagram illustrating an exemplary table structure. 

FIG. 6 is a functional block diagram illustrating an exemplary table for entity 
reference data. 

FIG. 7 is a functional block diagram illustrating an exemplary table for 
subscriber reference data. 

FIG. 8 is a functional block diagram illustrating an exemplary table for payer 
reference data. 

FIG. 9 is a functional block diagram illustrating an exemplary table for patient 
plan reference data. 

FIG. 10 is a screen shot illustrating an exemplary web page for a scoreboard 
displaying claim statistics by numerical count. 

FIG. 1 1 is a screen shot illustrating an exemplary web page for a scoreboard 
displaying claim statistics by dollar value. 

FIG. 12 is a screen shot illustrating an exemplary web page for displaying a 
claim listing rejected by the claim management system. 

FIG. 13 is a screen shot illustrating an exemplary web page for displaying a 
claim listing rejected by a payer. 

FIG. 14 is a screen shot illustrating an exemplary web page for displaying an 
editable HFCA 1500 form. 
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FIG. 15 is a screen shot illustrating an exemplary web page for displaying a 
claim history. 

FIG. 16 is a screen shot illustrating an exemplary web page for displaying an 
access list. 

FIG. 17 is a screen shot illustrating an exemplary web page for displaying an 
inbound file report. 

FIG. 1 8 is a screen shot illustrating an exemplary web page for displaying a 
rejection by a payer claim listing. 

Detailed Description of Embodiments 
The present claim management system is designed to provide integrated 
insurance claim submission, editing, and reporting. The system builds a complete 
record for each claim and standardizes the data. For that reason, the system captures 
every action related to the submission of a claim from a provider to a payer and all of 
the corresponding reports and messages that have been returned by the payer. 
Furthermore, the system stores this data related to a claim in a relational database. The 
unique cross-referenced data structure enables the viewing of the claim life cycle from 
unique perspectives. Each data table is linked such that all displays can directly 
provide desired information. The system's ability to organize the data in a 
standardized linkable format allows the data to be viewed in multiple ways that can 
vastly improve the percentage of claims that are paid by the payers, increase the 
amount paid per claim, and reduce the administrative expenses for both the provider 
and the payer. 

The system provides real time responses to claims submitted by a practice 
management system. The real time response allows claims to be edited at the time of 
submission. By processing claims at the time of submission, the provider receives 
instant notification about the claims. As a result, the provider can correct any claims 
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and immediately resubmit the corrected claims. This process eliminates delays for the 
provider in the payment process and results in fewer calls to the payer's support 
center. Consequently, the present system can dramatically reduce costs associated 
with claim processing for both the provider and the payer. 

The system operates as an application service provider (ASP). Claims can be 
uploaded from a practice management system (PMS) or entered directly from a web 
site. The claim management system (CMS) checks the claims to make sure they are 
in the appropriate format for the particular payer's requirements and that the 
information contained within the claim conforms to the appropriate content 
specifications. If the claim is incorrect, then the claim is rejected at the time of 
submission and the provider receives immediate notification via an online report 
which details the errors. At this point the provider has two options: 

1) correct the claims in their PMS and resubmit the claims; or 

2) select the rejected claims and correct the claims on-line. 

Once claims in the correct form are received, the CMS formats the claims according 

to each payers requirements and transmits the claims to the Payer. 

Thereafter, the payer applies its rules and either rejects or accepts the claims. 

This information is transmitted back to the CMS, where the information is readily 

accessible by the provider to determine a claim's status. 

The CMS reviews and categorizes the thousands of messages being returned by 
the various payers and assigns them a status based on the assigned rejection 
categorization. The general rejection categories include selecting from a group 
consisting of eligibility errors, duplicate claim errors, provider enrollment errors, 
coding errors, patient demographic errors, and payer information errors. The provider 
can use these status indicators to perform summary or detailed queries as to the overall 
status of their claims. In addition, the status summaries can provide a quick and 
efficient means to identify claims or billing procedures that require attention. 
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Additionally, the CMS establishes a profile for each payer that indicates which 
reports are expected back and when they should be received. In the event that a report 
is not received within the expected time frame, the CMS notifies the provider of the 
delay. Hence, the provider receives proactive reports indicating when important 
information is delayed. 

Lastly, the CMS reviews all of the informational messages being returned from 
the payers and edits the messages to insure that the provider can determine the 
problem based on the message being returned from the payer. The CMS will append 
additional information to the messages, when appropriate, to assist the provider in 
determining the appropriate corrective action. The provider can use the reporting tools 
to generate and view reports hierarchically on claim status for claims submitted by a 
particular physician, a group of physicians in a practice, a specific payer, a type of 
payer, a patient, a date of service, a message category, a specific error message or a 
particular office of a multi-office practice. This information allows the provider to 
quickly and efficiently identify problem areas that need correction. 

Hence, the CMS provides the status of a claim at all stages of its processing and 
reports indicating when claims have either rejected or when important information is 
delayed. 

Turning to the figures, in which like numerals indicate like elements throughout 
the several figures, FIG. 1 provides an overview of the claims management system 
(CMS) 10. A practice management system (PMS) 20 residing on a client site 
computer network system 12 maintains the practice records. The client system 12 
interacts with the CMS 10 to process the practice insurance claims. 

As shown in step Al, the PMS 20 uploads a claim batch file over a global 
computer network to a web server 14 within the CMS 10. The uploaded files are 
stored using the Internet File System (IFS) schema in the CMS database as shown in 
step A2. In the next step A3, a production server 18 processes the claim batch files. 
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The claims are parsed from the incoming EDI claim and set into standard ANSI ASC 
XI 2 Health Care Claim transaction set. During this processing, the system 10 ensures 
that the information contained within the claims conforms to the appropriate content 
specifications and all required information is provided. The processed claims are 
stored using the MGMT schema in the CMS database as shown in step A4. If a claim 
is incorrect, then the claim is rejected at the time of submission. As shown in step Bl, 
a report is immediately created using the REPORT schema. All known rejections are 
categorized by the CMS 10 and an easy to read description is attached as part of a 
report. If the rejection is a new rejection, personnel associated with the CMS 10, 
review the rejection to categorize the rejection and determine a readable explanation of 
the rejection. After receiving a rejection, generated reports will automatically provide 
the readable explanation of the rejection and a category determination for the rejection. 
Sorting rejection and status messages by categories enables a client to quickly 
determine where problems exist in their system. As shown by step B2, the web server 
14 immediately generates the rejection report and displays the online report to the 
client system 12 as shown in step B3 via the browser 22. At this point, the provider 
can correct the claims in their PMS 20 and resubmit a batch claim or select correct the 
claims online. 

A provider at a client system 12 can access the CMS 10 by using a well-known 
browser application 22 such as INTERNET EXPLORER 5.5 available from Microsoft 
Corporation. The client system 12 can correct claims, view reports, and even submit 
new claims online using the browser application 22. 

As shown in step CI, the client system 12 accesses the web server 14 within the 
CMS 10 using a commercially available web browser 22. After logging into the CMS 
10, in step C2, web screens are accessed from the WEB repository and presented to the 
client system 12. The on-line web screens enable the provider to enter new claims, 
edit rejected claims, and request various reports. All data provided by the web pages 
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are linked so that a user has the ability to drill down to the information desired without 
the necessity of loading specific screens to view the desired information. In step C3, 
new edits are processed using MGMT schema in real time by the production server 18. 
Instant feedback is provided to the client system 12. Each edit is stored using the 
MGMT schema to provide a complete claim history as shown in step A4. 

Upon acceptance by the CMS, a translator 16 formats the claims into the payers 
format as provided in step Dl. The translator 16 transmits the properly formatted 
claims over a global network to the payer computer network system 20 as shown in 
step D2. The payer system 20 applies its rules and either accepts or rejects the claims. 
The claim status is transmitted across a global computer network to the CMS web 
server 14 as shown in step D3. In step D4, the translator 16 formats the transmitted 
file data from the proprietary format of the payer into the standardized format utilized 
by the CMS 10. As shown in step D6, rejections are loaded into the CMS database 
using the MGMT schema. If claims are accepted, the accepted claim data is loaded 
into the CMS database using the ERA schema as illustrated by step D5. Accepted 
claims using the ERA schema are delivered to the web server 14 as provided in step 
D7 and provided to the client system 12 as shown in step El. 

The provider can access the CMS 10 at any time to view the current claim 
status, view summaries and reports, edit claims, or enter claims. Because all data 
tables are linked using a relational database, a provider can easily determine a claim 
status by activating a link to the claim status without the necessity of requesting a 
specific web page. As a result, any claim can be easily located and directly edited. 
Furthermore, categorizing claims into basic rejection categories allows a provider to 
easily determine what problems are being experienced in the claim processing system. 
Knowing the number and types of problems experienced with the claim processing 
system will enable a provider to make corrections to their practice procedures to 
reduce problem occurrences. 
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FIG. 2 discloses a logical software architecture of the CMS 10 constructed in 
accordance with an embodiment of the present invention. As will be understood in the 
art, the system is constructed utilizing Internet-enabled computer systems with 
computer programs designed to carry out the functions described herein. The 
computer programs are executed on computer systems constructed as described in 
reference to FIG. 3. Although the disclosed embodiments are generally described in 
reference to Internet-accessible computers, those skilled in the art will recognize that 
the present invention can be implemented in conjunction with other program modules 
for other types of computers. 

The disclosed embodiment of the present invention is implemented in a 
distributed computing environment such as the Internet. In a distributed computer 
environment, program modules may be physically located in different local and remote 
memory storage devices. Execution of the program modules may occur locally in a 
stand-alone manner or remotely in a client/server manner. By way of illustration and 
not limitation, distributed computing environments include local area networks (LAN) 
of an office, enterprise- wide area networks (WAN), and the global Internet (wired or 
wireless connections). Accordingly, it will be understood that the terms computer, 
operating system, and application program include all types of computers and the 
program modules designed to be implemented by the computers. 

The discussion of methods that follows, especially in the flow charts, is 
represented largely in terms of processes and symbolic representations of operations 
by conventional computer components, including a central processing unit (CPU), 
memory storage devices for the CPU, connected display devices, and input devices. 
Furthermore, these processes and operations may utilize conventional computer 
components in a heterogeneous distributed computing environment, including remote 
file servers, remote computer servers, and remote memory storage devices. Each of 
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these conventional distributed computing components is accessible by the CPU via a 
communication network. 

The processes and operations performed by the computer include the 
manipulation of signals by a CPU, or remote server such as an Internet web site, and 
the maintenance of these signals within data structures reside in one or more of the 
local or remote memory storage devices. Such data structures impose a physical 
organization upon the collection of data stored within a memory storage device and 
represent specific electrical, optical, magnetic, or similar elements. These symbolic 
representations are the means used by those skilled in the art of computer 
programming and computer construction to effectively convey teachings and 
discoveries to others skilled in the art. 

For the purposes of this discussion, a process is understood to include a 
sequence of computer-executed steps leading to a concrete, useful, and tangible result, 
namely, the effecting of an integrated claim management system. 

These steps generally require manipulations of quantities such as claim 
amounts, remittance data, service dates, identifiers of claims, patients, providers, 
billers, and payers, and other related transactional information. Usually, though not 
necessarily, these quantities take the form of electrical, magnetic, or optical signals 
capable of being stored, transferred, combined, compared, or otherwise manipulated. 
It is conventional for those skilled in the art to refer to these signals as bits, bytes, 
words, values, elements, symbols, characters, terms, numbers, points, records, objects, 
images, files or the like. It should be kept in mind, however, that these and similar 
terms should be associated with appropriate quantities for computer operations, and 
that these terms are merely conventional labels applied to quantities that exist within 
and during operation of the computer. 

It should also be understood that manipulations within the computer are often 
referred to in terms such as displaying, deciding, storing, adding, comparing, moving, 
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positioning, placing, and altering which are often associated with manual operations 
performed by a human operator. The operations described herein include machine 
operations performed in conjunction with various input provided by a human operator 
or user that interacts with the computer. In addition, it will be understood that the 
programs, processes, routines and methods described herein are not related or limited 
to any particular computer or apparatus, nor are they related or limited to any 
particular communication network architecture. Rather, various types of general 
purpose machines may be used with program modules constructed in accordance with 
the teachings described herein. Similarly, it may prove advantageous to construct a 
specialized apparatus to perform the method steps described herein by way of 
dedicated computer systems in a specific network architecture with hard- wired logic or 
programs stored in nonvolatile memory, such as read only memory. 

With the foregoing in mind, the drawing figures starting with FIG. 2 illustrate 
various functions, processes, or routines carried out by an embodiment of the present 
invention in which the disclosed CMS 10 carries out the functions described in 
connection with the flow charts and database maintenance. The functions or processes 
in these figures are carried out in the disclosed embodiment of the present invention by 
software executing in computers associated with CMS 10. Depending upon the 
particular operation, the computers are connected for data communications via a 
network such as the Internet. It will also be understood that the processes and methods 
presented here may be arranged differently, or steps taken in a different order. In other 
words, some processes and methods may be deleted, repeated, re-ordered, combined, 
or blended to form similar processes and methods. 

Turning now to FIG. 2, is a block diagram that illustrates a software 
architecture upon which an embodiment of the invention may be implemented. The 
CMS software is processed by a computing device 18. The computing device 18 
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comprises, at a minimum, a processor 54, memory 24, and an interface unit 58 all 
coupled together via a bus 56. 

The processor (or a plurality of central processing units) 54 executes the 
software modules 26-34. The memory device 24 coupled to the bus 56 stores 
information and instructions to be executed by processor 54. An operating system 52 
provides a platform for the execution of application modules. A business 
administration module 26 is operable for processing access rights for the client 
systems 12 to the CMS 10. A claims submission module 28 is operable for processing 
batch claim files transmitted submitted by practice management software 20 on the 
client systems 12 to the CMS 10. A HCFA 1500 module 30 is operable for detail 
claim viewing, claim editing and submitting claims online. A report module 32 is 
operable for generating reports. A service module 34 is operable to provide links to 
other services related to claim processing that a provider may desire. These modules 
execute the various functions of the CMS as will be described in greater detail in 
connection with the figures that follow. 

The aforementioned modules interact with the CMS database 80 to perform 
their functions. Tables within the CMS database 80 are divided into schemas based 
upon functionality. The practice management reference schema (REF) 48 is used to 
store current active practice management information including information related to 
entities, patients, insurance plans, subscribers, and profiles. The claims management 
schema (MGMT) 38 is used to process data related to claim editing. The associated 
tables contain information in connection with complaints, encounters, claims, and 
services rendered. The claim revision repository (REPOSITORY) 36 stores any 
changes made to REF 48 or MGMT 38 data. The repository captures claim history 
data. The remittance advice schema (ERA) 46 is used to process payer responses to 
submitted claims to the payer for payment. The report schema (REPORT) 40 is used 
as a basis to generate any reports. WEB schema 44 processes the CMS web screen 
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used to interface with the client systems. Claim batches submitted by legacy practice 
systems are stored and managed by the Internet claim files (IFS) 42 schema. The 
translator account schema (ECS) 50 is used to translate proprietary EDI files. The data 
described in the foregoing tables are functionally linked such that web pages viewed 
by the client system 12 links to desired claim information. 

The foregoing software architecture is executed on a computing device 18 that 
operates in a network environment. Operating network of the CMS 10 is illustrated in 
reference to Fig. 3. 

Fig. 3 illustrates an exemplary system network for the CMS 10. The CMS 10 
operates as an application service provider (ASP) over a global computer network 99 
such as the Internet. The hardware devices described in reference to FIG. 3 are well- 
known in the art and are commercially available. 

An intrusion detection system (IDS) 60' inspects all inbound and outbound 
network activity and identifies suspicious patterns that may indicate a network or 
system attack from someone attempting to break into or compromise a system. All 
messages entering or leaving the intranet pass through a firewall 62, which examines 
each message and blocks those that do not meet the specified security criteria. 
Another IDS 60" monitors traffic within the intranet for suspicious activity. An IDS 
management console 78 analyzes the information provided by the IDS monitors 60 
and presents this information to a network administrator. 

A web server 68 receives and transmits all Internet 99 communications. The 
web server 68 provides the CMS web pages to requesting client systems 12. 
Exemplary web utilized by the CMS 10 pages are illustrated in reference to Figs. 10 
through 18. These web pages allow a provider to submit or edit claims, view claim 
statistics, or view other reports, as will be discussed in reference to the associated web 
pages. The data presented by the web pages are linked such that specific claim 
information can be obtained by activating a link from the current web page without 
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having to request a specific web page. The web server 68 also receives the batch files 
transmitted from the client systems 10 and transmits reports to the client systems 10. 
The CMS 10 is maintained and updated by the staff computers 66 that reside behind an 
office router 64'. 

The core network 70 resides behind the firewall 62. A router 64" directs data 
packets to the appropriate device as addressed by the data packets. The core network, 
such as Ethernet network, connects the production server 18, the production data 
repository 80, a production translator 74, a development translator 76, and an IDS 
management console 78. In addition, a developmental server 72 and associated data 
repository 82 can be connected to the core network 70. 

A production translator 74 has a translation engine that converts data from one 
format into another and inserts or extracts data from the CMS repository 80. The 
translator 74 translates proprietary EDI formats into and from the CMS database 
format. A development translator 76 maintains a development version of a translation 
engine for converting EDI and other data formats to and from the CMS repository 82. 

The production server 18, such as a SUN 4800 model server, houses the oracle 
repository 80 for transaction data and executes the CMS modules. A majority of the 
functionality is contained within the CMS database 80, such as an ORACLE database, 
and utilizes an ORACLE programming language. A development server 72 maintains 
a development version of the ORACLE repository 82 and core modules. The data 
processing flow performed by the CMS 10 is illustrated in reference to Fig. 4. 

Turning now to Fig. 4A, illustrated is flow diagram illustrating another 
exemplary data flow process. The claim management system data flow process starts 
with Step G10, wherein a user logs into the application. Upon logging into the 
application the user is presented with a display, Step G12, that identifies the summary 
status of all claims that have been submitted to the CMS. 
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At this point the user can select to perform several actions through the 
application. The user can elect to correct rejected claims that are displayed in the 
summary status, Step G12, by clicking on the number indicator representing the 
number of claims in error, which in turn generates a list of the rejected claims, Step 
G14. The user can then select any of the claims from the list, Step G16, which in turn 
generates a new view showing the selected claim in detail, Step G18, as well as 
showing the entire list of claims from the previous view. The user can then use 
various tools to determine the appropriate action to be taken to correct and resubmit, 
Step G20, the claim. 

As part of the resubmission process the claim is checked against known generic 
and specific format and content requirements, known as edits, Step G22, to insure that 
the claim has been prepared correctly. If the claim passes the edits successfully then 
the YES branch of Step G22 is followed to Step G24. If the claim fails the edits then 
the NO branch of Step G22:is followed to Step G26 at which point the rejection is 
categorized and can then be displayed and made available for displaying via the Status 
Summary Display, Step G14, and through the Report Module, Step G52. 

To submit a claim file, the user would login to the application, Step G10, and 
then submit a batch of claims, Step G40. The batch would then be processed, Step 
G46, to determine that the claims were in the appropriate formats and loaded into the 
database, Step G48. If the batch was rejected the NO branch of Step G48 would be 
followed to Step G40 so that the file could be resubmitted. 

Returning to Step G22, Following the YES branch to Step G24 indicates that 
claims accepted for processing are in turn submitted to the Payers. If the payer accepts 
the claim batch then follow the YES branch from G28 to G32 to determine if the 
claims passed the Payers Edits. If the claims fail the payers edits then follow the No 
branch from G28 to G30 where the reason for the batch failure is investigated and 
resolved, at which point the file is resubmitted via Step G28. 
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If the claims pass the Payers claims edits Follow the Yes Branch to G34 
indicating that a Remittance Advice will be returned to the user with detail indicating 
payment status for the claims. If the claim is denied on the Remittance advice then the 
follow the NO branch from Step G36 to Step G60 where the rejection reason is 
categorized and made available for displaying via the Status Summary Display, Step 
G 14, and through the Report Module, Step G52. If the claim is paid then follow the 
YES branch from Step G36 to Step G38 indicating the claim is paid. 

Returning to the Step G10, after the user has logged into the application they 
can follow Step G50 to develop reports in order to analyze claim rejections by multiple 
criteria such as provider, facility, reason code, payer, patient, etc. This is 
accomplished by selecting the report module Step G52 and then utilizing report filters 
Step G54 to build reports. 

Once the selected claim is dispatched correctly a second claim is displayed 
from the error list for review. If the claim electing to display the or perform other 
activities such as submitting a batch of claims, Step G40, run reports, Step G50, or 
manage account privileges G56. 

For illustrative purposes lets assume that the user selects to perform all of these 
functions in which the claim submission module determines if a batch file processing 
request has been submitted by a PMS. 

Turn now to Fig. 4b, if a batch request has been submitted, the YES branch of 
step F10 is followed to step F12. If a batch request has not been submitted, the NO 
branch of step F10 is followed to step F18, in which web server application determines 
if a client system has logged into the CMS. 

In step F12, the batch claim file is processed. The proprietary EDI format is 
converted into a format utilized by the database engine. The PMS data is checked to 
ensure that the PMS authorized to use the CMS. The claims are then analyzed for 
format and eligibility errors. The claims are checked against standard rules and 
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specific rules of the associated payer. For example, certain service code identification 
codes have only five digits and have certain values representing the service provided. 
More specifically, a male patient would be ineligible for obstetric services and an adult 
would be ineligible for pediatric services. Rejection data by a provider system is 
analyzed to determine if new rules should be incorporated. 

After applying the rules in step F12 to the submitted claims, the claims are 
either accepted or rejected by the CMS in step F14. If the claims are rejected, the NO 
branch of step F14 is followed to step F16. If the claims are accepted, the YES branch 
of step F14 is followed to step F42, in which the claims are processed for submission 
to the payer. 

In step F16, the report module generates a report for the submitted file and 
provides the status of the claims and written description for all rejections. This report 
is transmitted over the Internet to the PMS that submitted the batch claim file. Step 
F16 is followed to step F10, in which the system awaits another batch claim file 
submission. 

The NO branch of step F10 is followed by step F18, in which the system 
determines if a client system has successfully logged into the CMS. If no successful 
login has been accomplished, the NO branch of step F18 is followed to step F10 
awaiting a batch file submission or a successful login to the CMS. If a client system 
successfully logs into the CMS, the YES branch of step F18 is followed to step F20, in 
which the CMS determines if a new claim submission is being dynamically requested. 
If a new claim submission has not been requested, the NO branch of step F20 is 
followed to step F26, in which a status summary web page ("the scoreboard") is 
displayed to the user. If a new claim submission has been requested, the Yes branch of 
step F20 is followed to step F22. 

In step F22, the system generates an electronic HCFA 1500 form web page. 
This form is an electronic simulation of the well known standardized paper claim 
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submission form used in the industry. This web page is illustrated in detail in 
reference to FIG. 14. The web page has data fields for the user to input the requested 
data or to edit the existing data. In step F24, the inputted data is checked against the 
general submission rules and any specific rules for that particular payer. Following the 
NO branch of step 24 to step F22, any input data that is not acceptable is immediately 
rejected and reported to the user, who can edit the information at that time. Upon 
proper input of all required information, the Yes branch of step F24 is followed to step 
F42, in which the claim is processed for submission to the payer. 

If a new claim is not being submitted, the NO branch of step F20 is followed to 
step F26. In step F26, the system provides a status summary web page ("scoreboard") 
to the user. This status summary web page provides an overview of the current status 
of all submitted claims by that office. A detailed description of the scoreboard is 
provided in reference to FIG. 10. The scoreboard has links to other reports and links 
directly rejected claims listing for editing rejected claims. Step F26 is followed by 
step F28, in which the system determines if the rejected claims listing link has been 
activated. 

If the rejected claims listing link is not activated, the NO branch of step F28 is 
followed to step F30, in which the system determines if another report is requested. If 
no additional report is requested, the NO branch of step F30 is followed to step F18, in 
which the system awaits another request. 

If another report is requested, step F30 is followed by step F32 in which the 
requested report is displayed. Exemplary reports are illustrated in reference to Figs. 
10-18. Step F32 is followed by step F28, in which the system awaits another request 
by the user. 

If the rejected claims listing link is activated, the YES branch of step F28 is 
followed to step F34, in which the system displays a listing of rejected claims. An 
exemplary web page providing a rejected claims listing is shown in reference to Figs. 
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12. Each rejected claim listing is linked such that activation of a link presents a HFCA 
form 1500 for editing. Step F34 is flowed by step F36, in which the system 
determines if a rejected claim is chosen for editing. 

If a rejected claim link is not activated, the NO branch of step F36 is followed 
to step F238, in which the system awaits another request by the user. If a rejected 
claim link is activated, the YES branch of step F36 is followed to step F38, in which 
the system displays a HFCA 1500 form web page for editing of the claim. Step F38 is 
followed by step F40, in which the system analyzes the claim edits against the claim 
rules to determine if the claims are acceptable to submit to the payer. If the claim edits 
are rejected by the CMS, the NO branch of step F40 is followed to step F38, in which 
the reason for the rejection is displayed and the claim detail web page is requesting 
additional edit input. If the claim edits are accepted, the YES branch of step F40 is 
followed to step F42. • 

In step 42, the system transmits the claims to the payer for payment. The 
translator formats the data into the data format required by that particular payer. The 
file is then electronically transmitted over the Internet to the IP address of the payer 
file server. 

Step F42 is followed by step F44, in which the CMS determines if the payer 
system accepts the file. If the file is formatted improperly for that payer, the payer 
system will reject the file. In which case the NO branch of step F44 is followed to 
step, in which the reason for the rejection is determined. The analysis of the rejected 
file is typically accomplished manually. The translator code is then updated to 
conform to the standards currently required by the payer system. Step F46 is followed 
by step F48, in which the file is reformatted and resubmitted t the payer system. Step 
F48 is followed by step F44, in which the CMS determines if the claim file has been 
accepted by the payer system. 
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If the payer system accepts the file for claim processing, the YES branch of step 
F44 is followed to step F50, in which the CMS determines if the claim has passed a 
substantive review by the payer system. 

If the claims have passed, the YES branch of step F50 is followed to step F54 5 
in which the remittance is processed. The claim and status data is updated to reflect 
the payment. Step 54 is followed by step F10, in which the system awaits additional 
requests by a user. 

If the claims have not passed, the NO branch of step F50 is followed to step 
F52, in which the rejection is categorized. If the rejection is a new rejection that has 
not been previously categorized, the claim rejection is manually analyzed. The 
rejection is placed into a broad rejection category and an easily readable description is 
attached to the claim rejection. Categorizing claims into broad rejection categories 
facilitate providers in determining where problems are occurring in the claim 
processing system. Attaching an understandable description to the rejection facilitates 
provider with claim rejection edits. Step F52 is followed by step F54 in which the 
claim data is updated to reflect the rejection. Step F54 is followed by step F16 in 
which a report is transmitted to the PMS. The report includes the claim rejection, the 
attached rejection description, and the rejection category. Step F16 is followed by step 
F10, in which the system awaits further requests by a user. 

The described data flow format describes merely an exemplary data flow 
process. Those skilled in the art will recognize that many variations of the above data 
flow can be used to accomplish the claim processing. The information used in the 
claim processing is stored in the CMS database 

Turning now to Fig. 5, the exemplary table structure illustrates the claim data 
model within the CMS. As previously discussed, tables within the CMS database have 
been divided into separate schemas based on functionality. Many of the tables defined 
within the database contain a set of common columns used for auditing and partioning 
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purposes. These common fields include a customer_entity, record_state, modified_by, 
timestamp, map_code, revision_no, day, and year. The customer_entity is a unique 
value that has been assigned to every customer group within the database. The 
record_state is a single byte character that indicates the current state of the record 
within the table. The modified_by field tracks which user altered information on the 
record. The timestamp records when the record was last modified. The map_code 
identifies the method the record was added to a table. The revision no allows the 
database to hold prior versions of the record. The day and year fields indicate the day 
and year the record was created. These fields should never contain null values. 

Table suffixes are used to help the developer understand the function of the 
table. There are currently four different table suffixes used. A profile table (_Profile) 
contains information relating to an entity that is relatively static but is specific to the 
entity type. A settings or parameter table (_Settings and _Parameters) contains 
information about an entity which changes often. As the application grows, new 
settings can easily be added without any database structure changes occurring by 
inserting new records into the table. Log (_Log) tables indicate a need to track the 
progression of an object through the database. For example, a claim status will change 
as it is moved within the system hence a claim Jog table. The current status will 
always be in the "ref 5 or "mgmt" table while the running history will be maintained in 
the "repository" table. Statistic tables (^Statistics) provide consolidated information 
(or metadata) about an object or entity. Unlike most other tables, statistical tables do 
not keep a revision history. Also it is assumed that internal processes maintain these 
tables so the column "modified_by" does not exist. 

Fig. 5 is a table structure for a claim data model. The data model illustrates 
tables that store information directly for the processing of claims. Other data tables 
(not shown) store auxiliary information for the processing of claims. The table 
structure illustrates the interlinking of the tables by common record columns. 
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The REF.ENTITIES table T10 maintains a revision history of all defined 
entities within the system. A listing of the REF.ENTITIES table T10 is provided in 
reference to Fig. 6. Specific information on the subscriber for that payer is maintained 
in the REF . SUB SCRIBERP A YER table T12. A listing of the 
REF.SUBSCRIBER_PAYER table T12 is provided in reference to Fig. 7. The 
REF. PA YERPRO VIDER table T14 maintains specific information on the payer for 
that provider. A listing of the REF .PA YERPRO VIDER table T14 is provided in 
reference to Fig. 8. The provider identification numbers (PINS) is maintained in the 
REF .PA YER_PRO VIDER PINS table T22. The billing agent information for that 
provider is maintained in the REF.BILLINGPRO VIDER table T20. 

The REF.PATIENTPLAN table T16 maintains specific information on 
insurance plan for that patient. A listing of the REF.PATIENT PLAN table T16 is 
provided in reference to Fig. 9. MGMT.CLAIMPATIENTPLAN maintains specific 
information on patient insurance for the claim being processed. 

The MGMT.CLAIMS table T28 maintains specific information about the 
current claim being processed. The MGMT.CLAIMSUPPLEMENTALINFO table 
T38 records supplemental information on a claim that is not recorded in other tables. 

The MGMT.CLAIM LOG table T36 maintains a log of the processing a claim. 
Claim log status codes are used to indicate the current state of the claim within the 
CMS System at the claim level. The codes themselves are grouped into ranges with 
generic meanings. Each specific code within the range a unique meaning. The code 
list has been assigned the "code_type" value of "20". The following table provides a 
description of the various code ranges used in the claim log: 



Code Range 


Generic Description/Purpose 


1-9 


Claim submission status codes to CMS 


10-19 


Claim internal edit codes 


20-29 


Claim forwarded to payer codes 


30-39 


Not Used 
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40-49 


Response from payer codes (These are not the payer's response 
codes but rather internal codes defined by CMS) 


50-59 


Other Filing Codes 


60-69 


Outbound formatting codes 


70-79 


Not Used 


80-89 


Not Used 


90-99 


Final Claim Status 



Specific Claim Status Codes: 



20#1 CLAIM BEING ENTERED 

2 0#2 CLAIM UPDATED 

20#5 CLAIM SUBMITTED TO CMS READY FOR EDITS 

20#10 EDITING CLAIM 

2 0#11 CLAIM FAILED EDIT PROCESS 

2 0#12 CLAIM ACCEPTED READY TO SEND TO PAYER 

20#13 RESUBMIT CLAIM TO PAYER 

20#14 CLAIM CANCELLED BY SUBMITTER 

2 0#15 CLAIM TRANSFERRED TO OUTBOUND STAGING AREA 

20#2 0 TRANSMITTING CLAIM TO PAYER 

2 0#21 CLAIM TRANSMITTED TO PAYER BY PAPER 

2 0#22 CLAIM TRANSMITTED TO PAYER ELECTRONICALLY 

20#40 PAYER ACKNOWELDGED RECEIPT 

20#41 PAYER REPORT RECEIVED 

2 0#42 REMITTANCE ADVICED RECEIVED 

2 0#43 CLAIM REJECTED BY PAYER 

20#44 CLAIM ACCEPTED BY PAYER 

2 0#45 CLAIM PAYED BY PAYER 

20#46 CLAIM DENIED BY PAYER 

20#51 SECONDARY FILING AVAILABLE 

2 0#52 TERTIARY FILING AVAILABLE 

2 0#53 PATIENT FILING AVAILABLE 

20#54 PATIENT BILLED 

2 0#60 TRANSLATING CLAIM FOR PAYER 

20#61 CLAIM WRITTEN TO OUTBOUND FILE 

20#99 CLAIM FILING COMPLETED 

2 0#91 WRITTEN OFF 

20#92 COLLECTIONS 

20#98 CLAIM CORRUPTED 



The example below illustrates the codes that may exist for a claim that has gone 
through the system. For simplicity only the relevant columns from tables have been 
shown. 

cms_mgmt . claim_log 

TIMESTAMP CLAIM_ID REVISION NO STATUS COMMENTS 
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08-JUN-01 


123456 


16 


£. \Jtt y y 




Claim 


filing complete 


cms_repository . 


claim_log 










TIMESTAMP 


CLAIM_ID 


REVISION NO 


STATUS 


COMMENTS 




Ol-JUN-01 


123456 


1 


£. Uff J. 




C~\ aim 

\ L Ct _L 111 


is being direct entered by 


customer 












Ol-JUN-01 


123456 


2 


20#1 




Claim 


xo Dciny uiicLL ciitcicu Jjy 


customer 












Ol-JUN-01 


123456 


3 


20#5 




Claim 


Vi^sci V»ci q 7-1 cni Vim n t~ t~ 0 ^ f- /-\ pvo 
Ilctb iJtitrll oUIJiiUULcU L.O V_i v io 


Ol-JUN-01 


123456 


4 


20#10 




Claim 


cro"i ncr t* Vi -rm 1 rrVi pHi t* r~\v~r\r>occi 


Ol-JUN-01 


123456 


5 


£. U+f -I- J- 




Claim 


failed Edit process 


03- JUN-01 


123456 




^ \j tt ~j 




Claim 


L _L .A-CvJ. Uy CUSLOUICI JL G dQy 


for edit 












03-JUN-01 


123456 


7 


U ft v 




Claim 


going tnrougn edit process 


03-JUN-01 


123456 


8 


20#12 




Claim 




04-JUN-01 


123456 


9 


6UffOU 




Claim 


oeing LiansiaCcu ror payer 


04-JUN-01 


123456 


10 


20#61 




Claim 


written to outbound file 


04-JUN-01 


123456 


11 


20#20 




Claim 


being sent to payer 


04-JUN-01 


123456 


12 


20#22 




Claim 


was transmitted 


electronically 












04-JUN-01 


123456 


13 


20#40 




Payer 


sent acknowledgement 


receipt 














07-JUN-01 


123456 


14 


20#41 




Payer 


sent report 


08-JUN-01 


123456 


15 


20#42 




Payer 


sent RA 


08-JUN-01 


123456 


-16 


20#99 




Claim 


filing complete 



Submit Date 
Transmission Date 
Payer Acknowledgement 
Payer Report 
RA Received 



= Timestamp of first occurrence of 20#5 

= Timestamp of last occurrence of 20#22 or 20#23 

= Timestamp of last occurrence of 20#40 

= Timestamp of last occurrence of 20#41 

= Timestamp of last occurrence of 20#42 



In this example 

CLAIM SUBM I T_DATE TRANSMISSION ACKNOWLEDGEMENT PAYER REPORT RA 



123456 Ol-JUN-01 



04-JUN-01 



04-JUN-01 



07-JUN-01 



08- JUN-01 



Related to the claim log, the MGMT.FILINGLOG table T30 maintains a log 
of the of the claim filing. Filing log status codes are used to keep track of the filing 
process at a claim level. For claims that are submitted only once, this information is 
duplicated information that could be found in the claim log table. However for 
multiple filings of the same claim to different payers this information is unique. The 
code list has been assigned the "code_type" value of "21". 
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There are a limited number of acceptable claim filing status codes. These codes 
should not be confused with payer codes sent back with responses. These codes are 
internal generic codes used to help control processing flow: 

21#1 READY TO SEND 

21#2 CLAIM SENT WAITING FOR PAYER RESPONSE 

21#3 RECEIVED PAYER RESPONSE 

21#4 RECEIVED REMITTANCE ADVICE 

21#5 PAYER FILING COMPLETE 



The example below illustrates the codes that may exist for a claim that has gone 
through the system. For simplicity only the relevant columns from tables have been 
shown. 



cms_mgmt.filing_log 

TIMESTAMP CLAIM ID REVISION NO PAYER STATUS COMMENTS 



08-JUN-01 123456 5 5 21#5 -- Claim filing complete 



cms_repository.filing_log 

TIMESTAMP CLAIM ID REVISION NO ' PAYER 



03- JUN-01 123456 1 5 
are passed 

04- JUN-01 123456 2 5 

07- JUN-01 123456 3 5 

08- JUN-01 123456 4 5 
08-JUN-01 123456 5 5 



STATUS COMMENTS 



21#1 -- Claim appears once edits 

21#2 -- Claim sent to payer 

21#3 -- Payer sent report 

21#4 Payer sent RA 

21#5 -- Claim filing complete 



Had a second filing occurred for this claim, the secondary payer would have been 
added to the filing log and the process would be repeated. Notice in this example that 
payer (3) does not return payer responses or RA so those statuses were intentionally 
skipped. 



cms_mgmt.filing_log 

TIMESTAMP CLAIM ID REVISION NO PAYER STATUS 



08-JUN-01 



123456 



03- JUN-01 
are passed 

04- JUN-01 

07- JUN-01 

08- JUN-01 
08-JUN-01 



123456 

123456 
123456 
123456 
123456 



21#5 



cms_repository.filing_log 

TIMESTAMP CLAIM ID REVISION NO PAYER STATUS 



21#1 

21#2 
21#3 
21#4 
21#5 



COMMENTS 

Claim filing complete 

COMMENTS 

Claim appears once edits 

-- Claim sent to payer 

Payer sent report 

Payer sent RA 
-- Claim filing complete 
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09-JUN-01 123456 6 3 21#1 -- New Payer secondary 

filing of claim 

09-JUN-01 123456 7 3 21#2 Claim sent to payer 

09-JUN-01 123456 8 3 21#5 -- Claim filing complete 

The MGMT.ENCOUNTERS table T24 maintains specific information about 
the encounter for the claim being processed. The MGMT. COMPLAINTS table T18 
maintains specific information on patient complaints about the claim being processed. 
The MGMT.DATESEGMENT table T34 maintains date information for the 
encounter. The MGMT. SERVICES table T32 maintains specific information about 
the services rendered by a provider for the claim being processed. 

The table structure illustrated in Figure 5 provides the framework for storing 
data concerning a claim submitted by a provider. Selected tables within the claim data 
model claim structure are presented in reference to Figs. 6-9. This data is processed 
by the CMS in accordance with the flow process previously outlined. 

Figs. 6-9 illustrate selected tables discussed in reference to the claim data model 
described in Fig. 5. 

Fig. 6 illustrates a REF. ENTITY table T10 that maintains a revision history of 
all defined entities with the CMS. The records associated with the table are listing in 
the Column Name column CIO. The data type column C12 provides the data type and 
size for the stored information within the database. The Nullable column C14 
indicates whether the associated field can be a null character. The Description column 
C16 provides a written description of the record. 

Fig. 7 illustrates a REF . SUB SCRIBERPA YER table T12 that maintains 
specific subscriber information related to a specific payer. The records associated with 
the table are listing in the Column Name column CI 8. The data type column C20 
provides the data type and size for the stored information within the database. The 
Nullable column C22 indicates whether the associated field can be a null character. 
The Description column C24 provides a written description of the record. 
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Fig. 8 illustrates a REF .P A YERPRO VIDER table T14 that maintains specific 
payer information related to a provider. The records associated with the table are 
listing in the Column Name column C26. The data type column C28 provides the data 
type and size for the stored information within the database. The Nullable column 
C30 indicates whether the associated field can be a null character. The Description 
column C32 provides a written description of the record. 

Fig. 9 illustrates a REF .P ATIENTS PL AN table T16 that maintains specific 
information related to a patient's insurance plan The records associated with the table 
are listing in the Column Name column C34. The data type column C36 provides the 
data type and size for the stored information within the database. The Nullable 
column C38 indicates whether the associated field can be a null character. The 
Description column C40 provides a written description of the record. 

Turning to Fig. 1 0, the screen shot illustrates an Internet web page W 1 00 
displayed by the CMS in response to a user successfully completing the login phase 
into the CMS. The scoreboard web page W100 displays the statistical information 
about the claims filed by the practice. Interactive web pages are well known in the art. 

A menu bar Wl 12 provides active links to various modules offered by the 
CMS. The Home button Wl 14 generates a scoreboard page W100 for display to the 
requestor.. The Business Admin button Wl 16 links to web pages that allow practice 
administers to set permissions for users within their practice to access or change 
information within the CMS. The Claim Submission button Wl 18 links to web pages 
that enable a user to submit new claim. The Report Menu button W122 links to a web 
page that enable the user to select desired reports. The Services button W122 links to 
a web page that provides links to services offered by other providers or to relevant 
information sources. The Support button W126 links to web page that offers technical 
support information and support personnel contact information. 
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The Scoreboard web page W100 has a Facility Office link W128 that when 
activated allows the user to select the current facility claim information for display as 
indicated by the Current Facility designation W132. The current user is indicated by 
the User designation W130. 

The scoreboard area W134 provides claim statistics for the selected facility. 
The user can set the desired date range by the Date Range selectors W136. The user 
can also select by the Display By selector W138 to view claims by count or by dollars, 
which is the dollar value associated with the claims in the category. 

The line designated as Clearing House WHO presents the status of claims as it 
passes from the practice to CMS. The Submitted Box W142 presents the number of 
claims or the dollar value of the claims that have been submitted to the CMS. The In 
Process Box W144 indicates the claims that have been accepted by the CMS and 
awaiting transmission to the appropriate destination. The Cancelled Box W146 
identifies claims that have been cancelled by the customer. The Rejected Box W148 
indicates the claims that have been rejected by CMS because of detected problems 
with the claim. 

The line designated as Insurance W152 presents the status of claims as it passes 
from CMS through the insurance companies adjudication system. The Submitted Box 
W142 presents the number of claims or the dollar value of the claims that have been 
submitted to the payer by CMS. The In Process Box W144 indicates the claims that 
have been submitted to the payers and are awaiting further reports. CMS establishes a 
profile for each payer and a claim stays in the In Process until all expected reports or 
acknowledgements have been received in the affirmative. The Cancelled Box W146 
identifies claims that have been cancelled by the customer. The Rejected Box W148 
indicates the claims that have been rejected by the payer. The Filing Complete box 
W150 indicates the claims for which CMS has received all of the anticipated 
affirmative reports. 
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Clicking on the number link in any of the boxes generates and presents a list of 
the claims for that box. By activating the Rejected box W148 on the CMS line W140, 
CMS generates and displays a list of claims that have been rejected for failing the 
CMS edits as illustrated in reference to FIG. 12. By activating the Rejected box W148 
on the Insurance line W152 5 CMS generates and displays a list of claims that have 
been rejected for failing the payer edits as illustrated in reference to FIG. 13. 

Turning to Fig. 1 1, the screen shot illustrates an Internet web page W200 
displayed by the CMS in response to a user the Display BY Dollars selector W138 
from the Scoreboard web page described in reference to Fig. 10. The web page W200 
displays the same claims filed by the practice illustrated in reference to Fig. 10 with 
the exception the data is presented in terms of dollar value of the claims rather than the 
number of claims in each category. 

Turning to Fig. 12, the screen shot illustrates an Internet web page W300 
displayed by the CMS in response to a user activating the Rejected link W302 on the 
Clearing House line W140. The web page W300 displays a Rejected List W304 of all 
claims that stand rejected by the CMS. The claims presented by this screen are listed 
in descending dollar amounts to focus attention on the most significant dollar claim 
amounts. Activating a Claim ID link W306 would cause the CMS to generate and 
display a detailed view of that claim on a HCFA 1500 web page that is illustrated in 
reference to Fig. 14. 

Turning to Fig. 13, the screen shot illustrates an Internet web page W400 
displayed by the CMS in response to a user activating the Rejected link on the 
Insurance line W152. The web page W400 displays a Rejected List W402 of all 
claims that stand rejected by the payer. The claims presented by this screen are listed 
in descending dollar amounts to focus attention on the most significant dollar claim 
amounts. Activating a Claim ID link W404 would cause the CMS to generate and 
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display a detailed view of that claim on a HCFA 1500 web page that is illustrated in 
reference to Fig. 14. 

Turning to Fig. 14, the screen shot illustrates an Internet web page W500 
displayed by the CMS in response to a user activating a Claim ID link W306 or W404. 
The web page W500 present a HFCA 1500 form. The claim input fields provide the 
user the ability to correct and resubmit the claim. Once a claim has been corrected and 
resubmitted, the next rejected claim is automatically loaded into the form for 
correction. Claim Status Display box W502 displays the current status of the claim. 
While the Claim Progress box W504 displays information about the progress of the 
claim, listing the date and time that action occurred related to the claim. A History 
link W506 links to a web page that display the entire claim history as illustrated in 
reference to Fig. 15. 

Turning to Fig. 15, the screen shot illustrates an Internet web page W600 
displayed by the CMS in response to a user activating the History link W506. The 
web page W600 displays the history related to that claim in the History box W602. 
The date and time, a description of the action, and the person performing the action are 
displayed. Each edit or change in claim information has been recorded and is 
displayed. Rejection messages are displayed in red for highlight. An Access Log link 
W604 displays a web page listing of every access to information related to the claim as 
illustrated in reference Fig. 16. 

Turning to Fig. 16 the screen shot illustrates an Internet web page W700 
displayed by the CMS in response to a user activating the Access link W604. The web 
page W700 displays an Access List W702 listing the names of all individuals who 
have accessed the claims. Limited access indication is used when the claim was 
included on a list but no clinical data was displayed. 

Turning to Fig. 17, the screen shot illustrates an In-Bound File Report W802. 
The Internet web page W800 is displayed by the CMS in response to all claims having 
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passed the CMS edits and indicates the status of the submitted claims. If any claims 
are rejected by the payer, those claims would be listed in the rejected box and 
highlighted in red. 

Turning to Fig. 18, the screen shot illustrates an Internet web page W900 
displayed by the CMS in response to a user activating the Count link . Activating any 
Claim ID link W902 would generate and display the HFCA form web page illustrated 
in reference to Fig. 14 to allow claim editing. 

In view of the foregoing, it will be appreciated that the present system provides 
an improved practice management claim processing system. It should be understood 
that the foregoing relates only to the exemplary embodiments of the present invention, 
and that numerous changes may be made therein without departing from the spirit and 
scope of the invention as defined by the following claims. Accordingly, it is the 
claims set forth below, and not merely the foregoing illustrations, which are intended 
to define the exclusive rights of the invention. 
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